Product documentation
The integration and behaviour between Mobile Field Service and Microsoft Dynamics 365 for Finance and Operations is controlled in the Microsoft Dynamics 365 for Finance and Operations environment. The mobile framework has a dedicated module from HSO Innovation, called 'Mobile Field Service - HSO'.
The module Mobile Field Service - HSO is not intended to be used in everyday operations by Microsoft Dynamics 365 for Finance and Operations users. Instead, the module will primarily be used for the initial deployment of Mobile Field Service, monitoring application performance and possibly issue solving. Access to the module is usually restricted to system administrators.
The parameter form contains the following items: General, Interface, Service Task, Call Creation, Project Category, Send to MFS and Maps. In the parameters the default behavior of the application is defined. For Mobile Field Service most parameters refer to how the HSO Innovation Service Management module, Project module and Inventory and Warehouse module process information from the mobile device.
It is possible that a password is forgotten or need to be changed for a reason. In that case select the engineer and option Reset password. When this is performed, Staging triggers need to be processed. From that moment on, the engineer can login with the new password.
If the user logs in with the old password (after a change), the following message will be displayed:
When the user logs in with the new password, the following message will be displayed:
The app is requesting to enter the previous password upon login in order to be able to open the encrypted database (in which the old password is still saved). If the user knows the old password it should be typed in and after synchronization, the new password will be saved in the database. If the user does not remember the old password, a forced initial load will be triggered and afterwards the user can login with the new password.
Active engineer devices with last synchronization date.
When the field Active is deselected, the engineer will not be able to synchronize anymore:
When a task status message is received from MFS, information is updated in the form Engineer status showing on which task the engineer is working, the status in MFS, the customer and actual location (latitude & longitude).
When a return item transfer is created or when a return is added via service task item usage in the MFS client, it is mandatory to enter a reason for this action. The options in MFS come from the setup table described above.
Here is the setup for all possible transfer reasons that are used in MFS:
The user can mark a warehouse as ‘Van warehouse’ via the Field services warehouse type field. These warehouses represent the warehouses of engineers and only for these type of warehouses inventory information is transferred to MFS.
Not all the events codes that exists in Microsoft Dynamics 365 for Finance and Operations, need to be used in MFS. To exclude some of them, open the Event code setup form and check ‘Exclude from Mobile Field Service’.
Not all the call types that exists in Microsoft Dynamics 365 for Finance and Operations, will need to trigger sending a service task to MFS. To exclude some of them, open the Call types setup form and check ‘Exclude from Mobile Field Service’.
Another adjustment has been made to the ‘Automatic call status update’ setup. Now it is possible to change call statuses not only as a result of service task status changes, but also as a result of Mobile Field Service statuses changes.
The field MFS Status has been added to the table. This column serves as a differentiation for when the rule may be applied. If the eventcode column is empty, it applies to any status/eventcode. Specific cases should have a higher priority (lower number) than generic cases.
In order to use the functionality to send email to the customer when task is finished you need to install and configure SMTP (Simple Mail Transfer Protocol) mail server in your environment.
To connect Microsoft Dynamics 365 for Finance and Operations to the SMTP server use the following procedure:
The following tables are send from Microsoft Dynamics 365 for Finance and Operations to MFS on initial load:
The Periodic section of the Mobile Field Service module contains primarily setups to control the frequency of information exchanges between the mobile device on one side and the Service Management module and Inventory module on the other side. It contains manual tools for loading information to the mobile devices as well as batch jobs to control periodic information exchange and updates.
‘Update item staging’ allows you to create a batch job for updating staged items with latest changes to item settings.
‘Update VAN inventory’ allows you to create a batch job for updating the inventory information for Van warehouses with latest changes to item and inventory information.
‘Update service object structures’ allow you to create a batch job for processing all date-effective active contents and compare the structure with the structure that is sent to MFS. If a change is detected an update trigger will be sent to MFS. If a service object is not part of any active content, a delete trigger will be sent to MFS.
‘Update service object staging’ allows you to create a batch job for updating staged service object with latest changes to service object settings.
‘Periodic update function’ allows you to run periodic MFS updates in a single batch instead of setting up batch jobs for each. It is recommended to run a batch for those once in a day or overnight to avoid message overload.
‘Process staging triggers’ allows you to create a batch job for processing messages sent from Microsoft Dynamics 365 for Finance and Operations Mobile Field Service module to the mobile devices.
‘Process inbound messages’ allows you to create a batch job for processing messages sent from the mobile devices towards the Microsoft Dynamics 365 for Finance and Operations Mobile Field Service module.
‘Periodic cleanup’ allows you to cleanup obsolete data in the Microsoft Dynamics 365 for Finance and Operations Mobile Field Service module, including obsolete engineer devices that may create a lot of unnecessary data if they are not removed.
Data cleanup helps with overall system performance by removing unnecessary data from the database. Therefore it is advised to run this cleanup at least once a month.
This cleanup window can be ran as a batch and you can set multiple cleanup jobs suiting your needs by running multiple batches. For example for device cleanup, one batch for every month and for logs another batch runs every day.
Note: Running all cleanup jobs for 0 days reset the MFS staging system completely. It is only recommended to do so if you setup a new test environment and want to start everything from scratch
You can cleanup obsolete engineer devices who did not synchronize their devices for certain number of days. Cleaned devices cannot login to AX anymore until they do a new installation of MFS application and validate their device again. Choose a value for “since before days” that you are sure the engineer who has not synchronized is sure having an obsolete device. Recommended values could be 90 days.
Clean the session log table for session information older than a certain of days. Session information in MFS is kept in the session log table for future investigation purposes. Sessions may stuck open if the device which was synchronizing is broken and cannot login to AX anymore and in time those data may cause unnecessary load. It is recommended to run this job to cleanup data older than 60 days.
Inbound messages (and inbound jobs) are the messages that has been received from MFS device to be processed to complete engineer synchronization. Messages received here are processed and kept if the message processed successfully (and parameter clean processed messages is unchecked) or message caused an error. Messages processed successfully and not cleaned up by MFS parameter can increase in size and cause unwanted performance loss. Therefore it is recommended to clean them up if they are older than one month once a month. Messages that are failed require your attention to solve the problem, therefore it is not recommended to clean those up unless you are sure that messages older than the days you set is already controlled by you and no solution has been found. It is not recommended to cleanup any of the received messages since they are not processed. This option exists only for setting up a new clean test environment by using 0 days value.
If you select logging engineer message traffic by setting up the MFS parameters for debugging purposes, this log can grow in size and hinder performance. It is recommended that you plan your testing and debugging so that you can clean up the message logs regularly. Recommended is to clean the logs everyday if you use request logging and once a week if you only use other log windows (such as outbound messages log).
‘Auto receive van transfer orders’ allows you to create a batch job for processing transfer orders with an engineer warehouse to change status from ‘shipped’ to ‘received’ automatically. As a result, item lines to be received on mobile devices are automatically processed. ‘Auto receive van transfer orders’ is regarded as optional functionality.
The Common section of the Microsoft Dynamics 365 for Finance and Operations Mobile Field Service module is designed to monitor inbound messages on the back office side of the interface.
The ‘Inbound messages’ form shows all messages that are received from MFS and it displays the user important information such as device and engineer who sends the message, received date, body length, message ID, session ID and message status.
The action pane is divided in four sections:
The Overview tab displays all inbound messages with information engineer name, device, received date, body length, message status, message ID and session ID. For a selected message the user can see information in the General tab:
The XML tab displays the content of xml message:
In Process log tab you can see the following information:
To avoid delays in inbound message processing, MFS creates inbound jobs for inbound processing operations that are slower and heavier to process, such as file attachments and mail sending. You need to process inbound jobs periodically just like you do with inbound messages.
The Inquiries section of the Microsoft Dynamics 365 for Finance and Operations Mobile Field Service module is designed to monitor staging triggers and other logs on the back office side.
The form ‘Engineer status’ gives an overview of all engineers that are using MFS on this Microsoft Dynamics 365 for Finance and Operations environment. Each status update coming from the device of the engineer will trigger an update of the engineer record in this table.
Staging triggers that are created, but not yet processed to MFS are displayed in this form. The user can delete selected record, refresh data that is displayed, cleanup all staging triggers or process trigger manually.
The form ‘Staging’ gives an overview of data that is staged for engineer to pick up. The status column gives the status of the staging. This is the biggest table in MFS and all staging operations are handled here, therefore it is not recommended modifying contents of this table directly.
The form ‘Session log table’ gives an overview of open and closed engineer data sending sessions. For security and to avoid data loss, all data sending and receiving in MFS are done through session tracking.
The form ‘Request messages log’ is where all of the engineer message traffic is logged for debugging purposes. Data in this form is controlled from the MFS parameter “Request message log” and if unchecked this data is not populated. It is not recommended to log engineer data on live environments, but test and production environments only for tracking and debugging.
The form ‘Outbound error log’ gives an overview of errors occurred during data sending process. Messages here can be used to spot problems with the connection or data. It is also possible to track invalid login attempts from this window.
‘Item validity check’ allows you to check if an item has a correct setup to be used in MFS.
Additional information regarding the use of items with Mobile Field Service:
Items from the Inventory module with a setup as described above will either not be loaded onto the mobile devices, or will cause info log stops when attempting to do transfers.